Imposing Transactional Properties on Distributed Software Architectures

speci cation language for the de nition of the integration rules. Hence, the rules become reusable abstractions that can be easily interpreted while taking into account several implementation details, speci c to the given computing system (e.g. implementation language, underlying communication platform etc.). Since in our execution model, components interact only through their interfaces, our speci cation language ends up to be quite simple. Its basic constituents are: declarations of components' interface instances, and operation calls on components' interface instances. 3 Design In this section we detail the basic design concepts relating to the framework's composing procedure. 3.1 Composing Steps Figure 2: Composing Procedure Figure 2 depicts the two basic steps of the composing procedure. During the rst step, the Integration Rule Assembler assembles the rules of all the selected services and deals with problems of interference and precedence order among them. The former issue raises in the case of using the composing procedure in the general context of a framework, like Aster [5], that deals with several di erent kinds of properties (e.g fault tolerance, security, transactions). The latter issue appears often in the current case study of synthesizing transactional middleware. Take for instance the combination of a service that provides locking with a service that provides atomicity. In this case, held locks must be released after the validation of the results produced by the transaction. If a service that provides time-stamps is selected instead of the locking one, timestamp validation must take place before the validation of the results produced by the transaction. During the second step, the Integration Rule Interpreter translates the assembled set of integration rules, resulting in the stub code that contains the hooks, which combine the services with the components of the system. 3.2 Integration Rules In the general case, we consider that integration rules are subdivided into the following: 4 Rules for the components that require operations (denoted by the keyword exportRules). Export rules are further subdivided into: Rules that de ne the actions that take place before issuing a request, denoted by the preExport keyword (e.g pack a platform speci c request). Rules that de ne the actions that take place in order to issue a request, denoted by the Export keyword. In the common case, this is the piece of code that calls a primitive action provided by the underlying communication platform so as to issue a request. Rules that de ne the actions that take place after a request is issued, denoted by the postExport keyword (e.g unpack the returned results). Rules that de ne the actions that take place once and only once, during the component initialization (denoted by the initExportRules keyword). Rules for the components that provide operations (denoted by the keyword importRules) which are further subdivided into : Rules that extend the interface of the components. In the common case, components' interfaces might inherit from an interface (denoted by the inheritFrom keyword), or they might contain an instance of an interface (denoted by the includes), provided by a middleware service. In that way, components inherit or include some basic features provided by the services. Rules that de ne the actions that take place before and after serving a request (denoted by the preImport, postImport keywords respectively). Rules that de ne the actions performed once and only once, during the component initialization (denoted by the initImportRules keyword). Rules that de ne the transaction model's signi cant actions (denoted by the transRules keyword), which are further subdivided into initiation and termination actions (denoted by beginTrans, endTrans keywords respectively). At this point, let us notice that in the case of existing services requiring the use of other services the integration rules can still be applied. However this is feasible only in the ideal case where the source code of the former services is available. 4 Example In order to exemplify our approach, we describe the synthesis of a simple software system based on services provided by the Arjuna [7] platform. The system follows the client/server execution model and realizes a simple distributed appointment system. Server components provide operations that can be used to add and remove an appointment, and an operation that returns the current time schedule. In such a system, it is reasonable to require a set of operations to be atomic and to further guarantee the isolated execution of clients that manipulate shared time schedules. Finally, it would be convenient to ensure that changes made to the time schedules will survive subsequent system failures. Hence, the system's requirements are: atomicity, isolation and durability. The Arjuna platform o ers three basic services, namely AtomicAction, LockManager and StateManager, which provide the aforementioned properties. The rst service provides ways to Begin, Commit, Abort a transaction, and upon transaction termination, it performs a two-phasecommit protocol. In Figure 3(a), we give the integration rules for that service. Basically, the 5 integration AtomicAction ::=integration LockManager ::=importRules ::=importRules ::=xInterface := null;xInterface := inheritsFrom LockManager;preImport ::= null;preImport ::=component lock ofType Lock;export new to lock;export setlock to this with lock;Import ::= null;Import ::= null;postImport ::= null;postImport ::= null;exportRules ::=exportRules ::=preExport ::= null;preExport ::= null;postExport ::= null;postExport ::= null;Export ::= null;Export ::= null;transRules ::=transRules ::=beginTrans begin ::=beginTrans begin ::= null;component transaction ofType AtomicAction;export Begin to transaction;endTrans commit ::= export Commit to transaction;endTrans commit ::= nullendTrans abort ::= export Abort to transaction;endTrans abort ::= null;(a) Integration Rules for the AtomicAction(b) Integration Rules for the LockManagerintegration AtomicAction ::=importRules ::=xInterface := inheritsFrom StateManager;preImport ::= null;postImport ::= null;exportRules ::=preExport ::= null;postExport ::= null;Export ::= null;transRules ::=beginTrans ::= null;endTrans ::= null;(c) Integration Rules for the StateManagerFigure 3: Integration rules for the distributed appointment systemintegration rules de ne the transaction model's initiation and termination actions. For example,to begin a transaction, an interface instance of the component AtomicAction must be declaredand the Begin operation must be called on this instance. The second service provides ways toacquire locks, using the setlock method, while it further guarantees that locks are acquired andreleased in a two-phased manner. The integration rules are given in Figure 3(b). According tothem, components that export operations must inherit from the LockManager class. A componentinstance (denoted by this) must call the setlock operation just before serving an incoming request.Finally, the third service ensures that the server components are recoverable. The rules are quitesimple (see Figure 3(c)), since the only guideline is that components that export operations shouldinherit from the StateManager class. To integrate the system's components with the Arjunaservices, the Rpc communication platform should be used. The Arjuna platform provides waysto pack and unpack Rpc requests meaning that the corresponding actions should be included inthe integration rules (in the de nition of the preExport, postExport and Export actions). However,6 these rules are omitted due to the lack of space.5 ConclusionIn conclusion, let us relate our proposal with some considerable early work, in order to pointout our contribution. We begin with programming environments like Venari/Ml [10], wherethe transaction concept is decomposed in a set of properties realized by object classes o ered bythe environment. The developer speci es application objects to be atomic, durable etc. Objectsthat adopt all the provided properties are fully transactional. The basic limitations are that theproperty set is not expandable and that the application objects are statically associated withthe properties (i.e. an object of the application cannot be used both as transactional and non-transactional, because its properties are de ned at compile time). In the same spirit of decomposingthe transaction concept, we meet the Raven system[2] and the approach proposed in [12]. Thenovelty is that properties are dynamically associated with the application objects. However, theproperty set remains closed and closely related to the underlying system (Raven and Hermes/Strespectively). An interesting approach that overcomes the closed property set limitation is presentedin [3]. According to that approach, the developer can require a particular transaction model,expressed in an Acta like language [1]. A formal framework is used to verify whether or not aset of application objects support this model. In case the model is not supported, a TransactionManagement Mechanism (Tmm) can be used to enforce the required constraints. Nevertheless, thelimitation is the non-expandable set of services. The whole framework is based on the Tmm unit.Thus, it lacks the exibility of using primitive transactional services and exploiting the di erentfeatures they provide (e.g. optimistic vs. pessimistic concurrency control).The method we introduced in this paper, aims to overcome the limitations of the aforementionedapproaches. Our goal is the synthesis of a transactional middleware platform based on an openservice repository associated to an expandable set of properties, that serves as the basic formalproving theory. Our method is based on: 1) the formal speci cation of transactional properties, 2)pure logical reasoning and 3) stub code generation.Our work is part of Aster 1, a framework that deals with the speci cation and automatedcomposition of software systems, regarding their requirements for quality of service (e.g. security,availability, transactions). The use of such a framework promotes software reuse, makes the ver-i cation of the resulted system a straightforward task, and nally eases the way to handle thesystem's evolution over time. In this work, we contribute by providing the basis for dealing withtransactional non-functional properties.Acknowledgments. We would like to thank Petr Tuma for his remarks and his contribution tothe realization of the framework prototype.References[1] P.K. Chrysanthis and K. Ramamritham. Synthesis of Extended Transaction Models UsingACTA. ACM Transactions on Database Systems, 19(3):450{491, September 1994.1Aster Url: http://www.irisa.fr/solidor/work/aster.html7 [2] D. Finkelstein, D. Acton, T. Coatta, N. Hutchinson, and G. Neufeld. Object Properties in theRAVEN System. In Proceedings of the 14th Conference on Distributed Computing Systems,pages 502{509. IEEE, June 1994.[3] D. Georgakopoulos and M. Hornick. Customizing Transaction Models and Mechanisms in aProgrammable Environment Supporting Reliable Work ow Automation. IEEE Transactionson Knowledge and Data Engineering, 8(4):630{649, August 1996.[4] IONA. Orbix Advanced Programers Manual. IONA Technologies Ltd, 1 edition, July 1995.[5] Valerie Issarny, Christophe Bidan, and Titos Saridakis. Achieving Middleware Customizationin a Con guration-Based Development Environment: Experience with the Aster Prototype.In Proceedings of the 4th International Conference on Con gurable Distributed Systems. IEEE,May 1998.[6] A. K. Elmagarmid. Database Transaction Models for Advanced Applications. Morgan Kauf-mann, San Mateo, California, 1992.[7] S. K. Shrivastava, G. N. Dixon, and G. D. Parrington. An Overview of theArjuna DistributedProgramming System . IEEE Software, pages 66{73, January 1991.[8] A. Mili, R. Mili, and R. Mittermeir. Storing and retrieving software components: A re nementbased system. In Proceedings of the 16th International Conference on Software Engineering,pages 91{100, 1994.[9] E. Moss. Nested Transactions and Reliable Distributed Computing. In Proceedings of theInternational Conference on Reliability in Distributed Software and Database Systems, pages33{39. IEEE, July 1982.[10] S. Nettles and J.M. Wing. Persistence + Undoability = Transactions. Technical ReportCMU-CS-91-173, School of Computer Science, Carnegie Mellon University, August 1991.[11] OMG. CORBAservices: Common Object Services Speci cation. Technical report, ObjectManagement Group, November 1995.[12] R.D. Ranson. Less-Than-Transactional Semantics for TINA. In 6th Telecommunications In-formation Networking Architecture Conference (TINA 95), volume 2, pages 243{257, 1995.[13] RM-ODP. Reference Model of Open Distributed Processing. Technical Report 10746, ISO/IECDocument, 1994.[14] Titos Saridakis, Christophe Bidan, Valerie Issarny. Using Nonfunctional Execution Propertiesto Classify Software for Reuse. In Franco-Japanese Workshop on Object-Based Parallel andDistributed Computing 1997 (OBPDC'97), 1997.[15] TRANSARC. Encina Toolkit Server Core Programmer's Reference, 1997.[16] Apostolos Zarras and Valerie Issarny. A Framework for Systematic Synthesis of TransactionalMiddleware. In Proceedings of Middleware'98. IFIP, Chapman-Hall, Sept 1998.8